A personal computer 10 (FIG. 1) includes a graphics processor 14 that generates a display of a three-dimensional (abbreviated as "3D") image on a screen 11 under the control of a central processing unit 15. Graphics processor 14 forms the displayed image 19 from graphics primitives describing the geometry of surfaces to be displayed (e.g. soda-can 17 and table 18), and render states (such as the soda-can texture and the table texture) that indicate the colors to be displayed in the surfaces.
An image displayed on screen 11 is typically formed by colors of a two-dimensional array of picture elements (called "pixels"). The pixel colors are normally generated by an application program being executed by CPU 15 in terms of graphics primitives (e.g. triangles and strips) that define the boundaries of various surfaces in the image, and render states (e.g. texture, culling, and fog) that define the appearance of the surfaces (e.g. brick, fur, etc). CPU 15 normally specifies each graphics primitive in terms of its vertices. Moreover, CPU 15 specifies each render state as two parts: a name (such as texture), and a value (such as brick).
A description (hereinafter "graphics API") of the format of such render states and primitives is provided in a book entitled "OpenGL Reference Manual, The Official Reference Document for OpenGL, Release 1," by OpenGL Architecture Review Board, Addison-Wesley Publishing Company, Reading, Massachusetts, 1992. See also the related book entitled "OpenGL Programming Guide" by Jackie Neider, Tom Davis, and Mason Woo, Addison-Wesley Publishing Company, Reading, Massachusetts, and another book entitled "3D Computer Graphics: A User's Guide for Artists and Designers" by Andrew S. Glassner, Design Press, New York.
In an example using the just-described API, when an image of soda-can 17 on table 18 is to be displayed, an application program executed by CPU 15 specifies one or more render states for soda-can 17, followed by one or more primitives for soda-can 17, and thereafter specifies one or more render states for table 18, followed by one or more primitives for table 18.
According to the API, the definition of render states is "sticky" in the sense that once a render state is specified, that render state need not be specified again until changed, i.e. each render state is effective for all graphics primitives that follow the render state, until the render state is changed. Therefore, if image 19 is to be shown as foggy, the application program being executed by CPU 15 merely turns on the fog state once, prior to specifying the soda-can primitives, and the fog state remains effective for the table primitives even though not explicitly specified. The graphics data (render states and primitives) that are generated by the application are normally processed by another program (called "graphics driver") that is executed by CPU 15. CPU 15 (when programmed with the graphics driver) "binds" the render states to the primitives by supplying these data together to graphics processor 14.
In a tiled architecture, graphics processor 14 divides screen 11 into rectangular areas (called "tiles") T1-TP, and each tile TI contains a number of pixels (e.g. 16 pixels) that form a portion of the displayed image. Each tile TI is held and processed one at a time in an on-chip memory (not labeled) included in graphics processor 14 (FIG. 1). Tiles T1-TP can be of any rectangular shape, but typically might be 32 pixels high and 32 pixels wide. For a screen having 640.times.480 pixels, there may be 300 tiles arranged in a rectangle that is 20 tiles wide and 15 tiles high.